The DBMS must support organizational requirements to disable user accounts after an organization-defined time period of inactivity.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-61717	O121-C2-013800	SV-76207r1_rule		Medium

Description
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Unused or expired DBMS accounts provide a means for undetected, unauthorized access to the database. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.

Description

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Unused or expired DBMS accounts provide a means for undetected, unauthorized access to the database. Note that user authentication and account management must be done via an enterprise-wide mechanism whenever possible. Examples of enterprise-level authentication/access mechanisms include, but are not limited to, Active Directory and LDAP This requirement applies to cases where it is necessary to have accounts directly managed by Oracle.

STIG	Date
Oracle Database 12c Security Technical Implementation Guide	2015-12-21

Details

Check Text ( C-62595r2_chk )
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding. For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed. If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding. - - - - - Check to see what profile a user is associated with, if any, with this query: SQL> select username, profile from dba_users where username = '&Enter_Username'; Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name. SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME'; - - - - - The following are notes on a method suggested by Oracle. In SRG-APP-000075-DB-000029 - The DBMS must, upon successful logon, display to the user the date and time of the user's last logon using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.logon_audit_info_all and trap logon information with a logon trigger. Check for the existence of the sys.logon_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue. $ sqlplus connect as sysdba SQL> select count(*) from SYS.logon_AUDIT_INFO_ALL; If the count is greater than zero, then the table exists and data is being inserted.

Check Text ( C-62595r2_chk )

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, this is not a finding.

For accounts managed by Oracle, check DBMS settings to determine if accounts can be automatically disabled by the system after 35 days of inactivity. Also, ask the DBA if an alternative method, such as a stored procedure run daily, to disable Oracle-managed accounts inactive for more than 35 days, has been deployed.

If the ability to disable accounts after 35 days of inactivity, by either of these means, does not exist, this is a finding.

- - - - -
Check to see what profile a user is associated with, if any, with this query:

SQL> select username, profile
from dba_users
where username = '&Enter_Username';

Then check the profile to see what the password_life_time is set to in the table dba_profiles; The password_life_time is a value stored in the column named resource_name.

SQL>select profile, resource_name, resource_type, limit from dba_profiles where upper(resource_name) = 'PASSWORD_LIFE_TIME';

- - - - -
The following are notes on a method suggested by Oracle.

In SRG-APP-000075-DB-000029 - The DBMS must, upon successful logon, display to the user the date and time of the user's last logon using a custom trigger for this event. One could query the audit table and get similar results, but that is a much busier table with a lot more data. In SRG-APP-000075-DB-000029, we advocated to use a new table called sys.logon_audit_info_all and trap logon information with a logon trigger.

Check for the existence of the sys.logon_audit_info_all and count the number of rows to ensure that the table is being used. Obviously, the table will have maintenance performed on it to shrink the contents, so the number of rows may vary. If the table itself exists, it is a good indication it is being used. Connect to the database, check for the existence of the table, and count the rows, as this will help us understand if the fix for SRG-APP-000075-DB-000029 was implemented and will help us remediate this issue.

$ sqlplus connect as sysdba
SQL> select count(*) from SYS.logon_AUDIT_INFO_ALL;

If the count is greater than zero, then the table exists and data is being inserted.

Fix Text (F-67633r1_fix)
If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required. For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement: ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35; (See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.) If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days.

Fix Text (F-67633r1_fix)

If all user accounts are managed and authenticated by the OS or an enterprise-level authentication/access mechanism, and not by Oracle, no fix to the DBMS is required.

For accounts managed by Oracle, determine if it is practical and acceptable to require a password change every 35 days or fewer, rather than the standard 60 days (as specified in SRG-APP-000174-DB-000080). If it is, issue the statement:
ALTER PROFILE PPPPPP LIMIT PASSWORD_LIFE_TIME 35;
(See the Oracle-provided $ORACLE_HOME/rdbms/admin/secconf.sql script for examples.)

If password changes every 35 days or fewer are unacceptable or impractical, implement an alternative method, such as a stored procedure run daily, to disable accounts inactive for more than 35 days.